The present invention relates to the field of asset management and, more particularly, to identifying stray assets in a computing environment and responsively taking resolution actions.
In today's large-scale computing environments, interaction between components and/or assets are often complex. Because of this, specially-designed software tools have been developed to allow users to create configuration items at a high-level (or variable level) of abstraction. Configuration items (CIs) can be for relatively persistent assets, such as those having a lifetime that extends over weeks, months, or even years. Configuration items can also be defined at the transactional level. Software tools for CIs allow users to use graphics and/or natural language constructs to express the environment assets. The tools also permit users to manipulate, monitor, and combine environment assets at the asset level, hiding the deeper complexities and interactions.
For example, a software tool can allow a user to express a step of the process/workflow simply as “Create an Application Server”. Thus, the user need not understand the specific steps and system details required to fulfill this step of the process/workflow; only that the tool will translate this statement into the proper code that will create the application server and all related changes required to make the server accessible.
Unfortunately, these deeper complexities and interactions are also often hidden from other systems (e.g., a configuration management (CM) or software management system) that monitor and keep the components/assets of the computing environment in the proper working order. Using the above example, a monitoring system would be capable of determining that there is a relationship between the requesting service/application/asset and the inventory database. However, such systems are typically unable to identify or handle the auxiliary actions that are sometimes required to enact the workflow/process step.
For example, a modification may need to be made to the firewall configuration (i.e., a firewall “pinhole”) in order to for the requestor to access the application server. Since the monitoring system is unaware of this additional side process, the change to the firewall remains after the step of the workflow/process is completed and is accessible to any other service/application/asset, internal or external, whether or not required.
Thus, when the asset (i.e. application server) is relinquished, the high-level of abstraction provided by process/workflow definition tools have created situations within the computing environment where functionality is left stray and unresolved.